Field of the Invention
The present invention generally relates to computer systems, and more particularly to a method of implementing database security with access control.
Description of the Related Art
Computer system and software designers have devised a variety of security features to restrict access or grant privileges to different aspects of a computer program. The most common of these is a unique user identifier or username which is usually provided in combination with a confirmation code or password. This login information allows a user to be authenticated, and then corresponding access controls can be implemented according to the particular computer system involved.
One example of a computer system which provides for user authentication and access control is a database server. The term “database server” denotes a computer system which retains information in the form of a database and provides that information to users (database clients). The hardware for a database server might be a single computer system, but often a single “server” is actually composed of multiple computers, e.g., multiple server drawers in a rack with each server drawer providing various processing functions. A server may have a centralized memory device, or may use a distributed memory system. The information in the database may be stored in various conventional formats, using custom or off-the-shelf products such as Oracle, DB2, IBM Informix, or Microsoft SQL (this list is not exhaustive).
These and other popular databases have internal mechanisms (e.g., roles and privileges) for controlling database user access to database objects, sometimes referred to as a database access control module (DACM). The following are examples related to an Oracle database, where a privileged database user or database administrator restricts access on a database table “EMP” for database user “ALICE”:
REVOKE UPDATE, INSERT, DELETE ON TABLE EMP FROM ALICE;
GRANT SELECT ON TABLE EMP TO ALICE;
Based on these database statements, ALICE will be able to read from table EMP, but will not be allowed to make changes.
DACMs are very effective , but from security systems point of view they are not comprehensive. They control database users and their access to database objects only. DACMs do not deal with parameters external to database server, like network addresses (internet protocol, or IP, addresses), operating system user, media access control (MAC) addresses, etc. DACMs are also security vulnerable because they do not support the “separation of duties ” (SoD) concept and can be managed by power database application users or uncontrolled database administrators. The idea of protection of database objects (supporting the SoD concept) is embodied in network database access control systems (DACS), for example, such as the system described in U.S. Pat. No. 7,904,454. Local DACS (LDACS) is very important in intrusion detection systems. Its ability to control secured database access and access to database from privileged local users like database administrators is an advantage over network DACS.
The leading solution of LDACS is implemented in the Infosphere Guardium product marketed by International Business Machines Corp. One example of LDACS processing 2 is seen in FIG. 1. A database client 4 wants to communicate with a database server host 6 over a network 8, such as a local area network (LAN) or the Internet. Database client 4 begins the communications by providing session login information. Database server host 6 includes a lightweight agent 10 and a database server 12. Agent 10 intercepts all requests sent between database client 4 and database server 12 on an inter-process communication (IPC) level without secured access or cryptographic method invocation level with secured access. Agent 10 is not aware of any database protocols. It forwards a packet containing intercepted requests through a network 16 (which may or may not be the same as network 8) for further analysis to an external security device (ESD) 14 residing outside of database server host 6. Agent 10 holds the database client request and waits for a decision (verdict) from ESD 14. ESD 14 extracts information about the accessed database object and validates database session security policies. If a security policy would be violated by the request, then ESD 14 responds to agent 10 with a verdict such as “DROP DATABASE SESSION” which means that agent 10 must interrupt the database session. If no security policy is violated by the request, ESD 14 responds to agent 10 with the verdict “RELEASE DATABASE REQUEST” which means that agent 10 will release the database client request to database server 12. Analysis of database requests and security policies validation are CPU and memory intensive, so it is advantageous to pass these functions to ESD 14. Further details of LDACS processing can be found in U.S. Pat. Nos. 7,426,512 and 8,495,367, which are hereby incorporated.